A common task in radio communication systems is handling the behavior of a user terminal upon detection of a radio link failure (RLF). In a known approach to recovering from a radio link failure, the user terminal makes a random access to the cell where it is located. Thereafter, and upon allocation of resources from the network, the mobile terminal sends a message informing the network that it has experienced a radio link failure and is trying to re-establish its connection. In the latest version of the controlling specifications for Long-Term Evolution (LTE) systems, as standardized by the 3GPP, the reconnection message is called a “Radio Resource Control (RRC) Connection Re-Establishment Request.” Particularly, in 3GPP LTE, three RRC messages are exchanged during RLF recovery: (i) RRC Connection Re-establishment request from the user terminal (referred to as a UE in LTE) to a base station (referred to as an eNB in LTE); (ii) RRC Connection Re-establishment from the eNB to the UE; and (iii) RRC Connection Re-establishment complete from the UE to the eNB.
More generally, in case of a radio link failure, a given user terminal may synchronize with the cell where it is located, listen to the broadcast channel of that cell, and subsequently make a random access attempt therein. Upon a successful random access attempt, the user terminal is assigned the necessary resources to transmit its request for radio bearer re-establishment. A primary aim is that the user terminal performs the RLF recovery procedure with a minimum time delay such that the connection is maintained. Recovery delays are reduced when the random access attempt and the associated Layer-3 (L3) message transmissions are done in favorable radio propagation conditions. The time needed for recovery also depends on whether or not the cell to which the user terminal attempts recovery already possesses the user context for the user terminal.
That is, user context information is needed to recover the user terminal's radio link, so not having user context at the cell where recovery is being attempted causes delays while user context information is transferred or otherwise provided to the cell. Commonly, if it is not already present in the cell being used for recovery, user context information must be fetched from the user terminal's last serving cell. The time needed for fetching may be considerable as, for example, the information comprising the user context can include physical layer identity, Medium Access Control (MAC) identity, temporary terminal identity, transport channel and logical channel parameters, Radio Link Control (RLC) buffer status, RLC timers and parameters, ciphering parameters, etc.
User context is maintained in a user terminal's serving cell, e.g., at a base station controlling the serving cell. Thus, if the user terminal remains within the coverage area of its last serving cell after experiencing a radio link failure, its user context information will already be available at the serving cell base station, for use in quickly recovering a radio link to the user terminal. However, according to existing approaches to recovery, user terminals attempt recovery in given cells without benefit of knowing whether such cells have their user contexts available for quick recoveries of their radio connections.
More precisely, according to TS 36.331, the user terminal upon detection of radio link failure tries to synchronize to the system (in case it has lost its synchronization) and then starts measuring on the pilot channels, so as to detect the cell yielding the strongest signal. Once this is done, the user terminal listens to the broadcast channel of the selected cell and then attempts a random access in this designated cell. Hence, the user terminal performs radio link failure recovery to the cell which is yielding the strongest pilot signal, without any knowledge of whether this cell has the UE context.
For example, a common scenario for radio link failures is the user terminal performing a handover from a source (serving) cell to a handover target cell. When handover is triggered for a given user terminal, it is very likely that the serving cell radio link for that user terminal is experiencing considerable loss rates. Thus, even if the serving cell can be detected by the user terminal after a handover-related RLF and random access attempts can be performed to that cell, it is likely that the radio conditions with respect to the serving cell are not good enough to support reliable reconnection. Therefore, the user terminal likely will look for another cell in which to reconnect, without benefit of knowing whether that other cell has its user context. Indeed, it may be that the user terminal cannot even detect its last serving cell after experiencing a handover-related RLF.
Another known recovery approach, therefore, is the user terminal attempts a radio access to the cell that offers the best radio link to the user terminal, according to the last measurements done. However, this option is optimal only in cases where the user terminal is aware of the cell which offers the best link, at the moment the user terminal initiates the radio link failure recovery procedure. This option exists, e.g., in case of handover failures where the last measurement that has been done by the user terminal indicates that the best cell is the (handover) target cell. If the user terminal has indeed moved to the target cell, the target cell is the cell exhibiting the best radio propagation conditions. However, there might be other cases where this assumption does not hold, e.g. in case the radio link failure occurred during handover procedure and a user terminal, which moves with high speed, initiates the radio link failure recovery procedure when the user terminal is not anymore in the target cell. As mentioned above, this last cell (target cell) was supposed to be the cell offering the best signal quality to the user terminal, according to the latest measurement done by the user terminal. Even in this case it might be possible for the user terminal to perform measurements so as to detect the best cell and then try to perform random access and, consequently, the radio link failure recovery procedure. However, this procedure (i.e. the user terminal measures thoroughly so as to estimate the best cell, or decodes the synchronization sequence or pilot channel of this cell so as to get information on its characteristics, i.e. timings of the random access channel, in case the terminal has lost its synchronization) requires time; this time might be shortened in certain cases. The user terminal may also read the broadcast channel of this cell to acquire the system information.
Considering also that it is beneficial purely from the connection continuation point of view to try to connect to the serving cell, where the user terminal context is certainly available, in previous to 3GPP LTE systems and, initially, within 3GPP LTE, it was suggested that upon detection of a “radio problem,” the user terminal tries during a time period T1 to re-establish an RRC connection to the serving cell. However, this approach to reconnecting is not always necessary, such as where it is improbable that the user terminal has remained in the previous serving cell where it lost connectivity.
For illustrative purposes and for the sake of exemplifying the above described problems, a more detailed description of the RLF recovery procedure in 3GPP LTE follows. In 3GPP LTE, as in current and previous radio communication systems, when a radio link failure (or “radio problem”) is detected by a user terminal, a procedure to re-establish its radio link connection with the network is performed. After the radio problem detection, the user terminal might be able to maintain its synchronization with its last serving cell, or not. In case the user terminal loses its synchronization with its serving cell, the first step in the RLF recovery procedure is the user terminal trying to synchronize with a cell of the network.
Usually, this cell is the cell that the user terminal receives with the strongest received signal strength over the pilot channel. In some cases, this cell might be the one that the user terminal detects first, without this cell being necessarily the strongest one. Upon synchronization to the selected cell, the user terminal listens to the cell's broadcast channel. After having acquired the necessary information from the cell's broadcast channel, the user terminal attempts a random access in the cell.
Upon a successful random access attempt, the user terminal transmits a Layer-3 signaling message, indicating that the user terminal is trying to recover from a radio link failure. In 3GPP LTE, this message is termed an RRC Connection Reestablishment request. The cell ID of the last cell to which the user terminal maintained an active connection might be included as part of the request message. If the cell selected for reconnection by the user terminal already possesses the user terminal context, the RRC connection reestablishment starts. FIG. 1 illustrates the steps involved in a conventional approach to RLF recovery, where the user terminal has lost its synchronization to its serving cell (in 3GPP LTE this procedure starts upon expiry of a timer T310).
According to the illustrated process, the user terminal detects radio link failure (Block 100), and selects a cell (e.g., based on signal strengths) for attempting to recover its radio link (Block 102). The procedure continues with the user terminal listening to a broadcast channel of the selected cell to obtain information for making a random access on a reverse-link random access channel (RACH) (Block 104), and then performing a random access (Block 106). Upon gaining a corresponding resource allocation (Block 108), the user terminal uses the allocated resources to send an RRC connection reestablishment request message (Block 110), and then carries out RRC connection reestablishment (Block 112) to completion (Block 114).
In case of an RLF recovery attempt within a cell which does not possess the user context for the user terminal, the cell has to request the user context from the last serving cell of the user terminal, assuming that communication between these two cells is possible. If the transfer of user context fails or is not possible, the network directs the user terminal to idle mode and a new RRC connection may be established. Signaling information consisting of the user context is then exchanged between the user terminal and the new serving cell. The amount of information required for the establishment of an RRC connection is not insignificant; hence, the time required for this procedure is considerable.
The above mentioned procedure might result in the user terminal performing random access to the cell that yields the strongest signal to the terminal. However, in scenarios, where the user terminal is located in an area overlapped by multiple cells and is moving fast, it may detect strong signals from more than one cell. In such scenarios, a more elaborate method would be that the user terminal synchronizes to the system and then measures the signal strengths received from the various cells so as to select the cell yielding the strongest signal strength. FIG. 2 represents this more elaborated procedure, where processing begins with the user terminal detecting radio link failure (Block 120), synchronizing with the system (network) (Block 122), and measuring the received signal strength from the cells within its location area (Block 124). Upon detecting and selecting the strongest cell in the location area (Block 126), the UE listens to the broadcast channel (Block 128) of the selected cell. Subsequently, the user terminal performs random access in the strongest cell (Block 130) to request signaling resources. Upon gaining such resources (Block 132), the user terminal sends an RRC connection reestablishment request message (as a Layer 3 message) (Block 134), and carries out reconnection procedures (Block 136) to completion (Block 138).
In the above described procedure, the user terminal ensures that the cell it selects for attempting recovery offers good radio conditions; indeed, it selects the best cell in terms of signal strengths from among the cells it detected. However, it may be that the selected cell does not have the user context for the user terminal. Recovery will be delayed in such cases.